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computer  software  management  and  compare  with  the  approach  being 
implemented  for  the  combat  control  system  aboard  Fast  Attack 
Nuclear  Submax'ines. 


STUDY  REPORT  ABSTRACT:  Current  DOD  and  Navy  policy  and  procedures 
are  reviewed  and  compared  with  current  procedures  being  imple- 
mented to  manage  computer  software  aboard  Fast  Attack  Nuclear 
Submarines  (SSNs).  The  specific  area  of  comparison  is  the  Life 
Cycle  Support  of  the  operational  software  for  the  combat  control 
system  aboard  SSNs.  Conclusions  and  recommendations  of  the  re- 
view are  provided  for  the  program  manager  within  the  Naval  Sea 
Systems  Command. 
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The  purpose  of  this  report  is  to  review  DOD  and  Navy 
Policy  and  procedures  for  computer  software  management ; com- 
pare this  DOD  and  Navy  Policy  with  the  approach  now  being 
implemented  for  the  combat  control  system  aboard  Fast  Attack 
Nuclear  Submarines  (SSNs). 

DOD  and  Navy  documentation  governing  operational  software 
management  is  identified  with  the  pertinent  sections  high- 
lighted and  presented  as  the  basis  for  comparison  with  the 
approach  being  implemented  for  the  combat  control  system. 

The  details  of  the  organization  and  the  procedures  governing 
the  combat  control  systems  operational  software  management 
are  discussed. 

The  review  concludes  that  the  current  procedures  being 
implemented  are  conforming  to  DOD  and  Navy  policy.  In 
addition  two  recommendations  are  made  to  improve  the  combat 
control  computer  software  life  cycle  management. 
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SECTION  I 
INTRODUCTION 

1.  BACKGROUND 

Introduction  of  computers  into  major  weapon  systems  dates 
back  more  than  three  decades;  these  computers  were  of  the 
hard- wired  analog  type.  However,  embedded  digital  computers 
have  been  used  in  weapon  systems  for  more  than  a decade.  The 
trend  has  been  to  eliminate  hard-wired,  limited  purpose  weapon 
systems  and  replace  them  with  high  speed,  digital  computer, 
multipurpose  weapon  systems.  This  approach  was  taken  such 
that  a weapon  system  would  have  increased  flexability  to  meet 
an  ever  increasing  military  threat . With  the  increased  flexa- 
bility additional  advantages  are  also  envisioned,  such  as 
reduced  time  to  counter  a new  threat , reduced  manpower  to  both 
operate  and  maintain  the  equipment  as  well  as  reduced  weapon 
systems  cost . 

In  recent  years  there  have  been  substantial  increases  in 
the  time  required  to  reprogram  the  digital  computer  driven 
weapon  systems  and  increases  in  cost  as  well  as  increases  in 
operator  and  maintenance  personnel . These  increases  have 
helped  drive  the  Defense  Budget  to  a souring  approximate  $120 
billion  dollars  for  FY  1978.  The  contributions  due  to  com- 
puter hardware  and  software  are  not  clearly  identifiable. 
However,  predictions  of  future  requirements  indicate  that 
software  cost  will  be  approximately  eighty  per  cent  of  the 
total  computer  cost  by  1985.  The  Deputy  Assistant  Secretary 
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of  Defense  for  Material  Acquisition,  Jacques  Gansler,  was 

guoted  in  a 1976  Aviation  Week  (R9i41)^  as  saying  "According 

to  our  estimate,  the  Pentagon  is  spending  more  than  three 

billion  annually  for  software  for  defense  systems."  Top  DOD 
fw 

officials  as  well  as  Congress  have  initiated  action  to  deter- 
mine the  reasons  for  the  increases  as  well  as  initiated  action 
to  control  the  cost . 

Within  DOD  several  studies  have  been  undertaken  and  new 
policies  and  procedures  have  been  established.  The  most 
recent  policy  is  DOD  Directive  5000.29;  Management  of  Computer 
Resources  in  Major  Defense  Systems,  dated  26  April  1976  (Dl). 
This  directive  establishes  policy  for  the  management  and 
control  of  computer  resources  during  the  Life  Cycle  of  major 
defense  systems.  The  topics  identified  in  the  policy  are  out- 
lined as  follows: 

A.  General 

B.  Requirements  Validation  and  Risk  Analysis 

C.  Configuration  Management  of  Computer  Resources 

D.  Computer  Resource  Life  Cycle  Planning 

E.  Support  Software  Deliverables 

F.  Milestones  Definition  and  Attainment  Criteria 

G.  Software  Language  Standardization  and  Control 

^This  notation  will  be  used  throughout  this  report  for 
sources  of  quotations  and  for  major  references . The 
first  alpha  numeric  designator  is  the  source  listed  in 
the  bibliography.  The  second  number,  after  the  colon, 
is  the  page  number  in  the  reference. 


2.  STATEMENT  OF  PROBLEM 

The  U.S.  Navy  is  currently  deploying  Fast  Attack  Nuclear 
Submarines  (SSNs)  that  have  high  speed  digital  computers  as  the 
heart  of  the  weapon  system.  The  systems  on  a single  ship  have 
software  programs  that  are  approaching  a million  words  of 
instructions.  These  weapon  systems  were  designated  to  have  a 
great  deal  of  flexiability  by  being  reprogrammable  to  meet  new 
missions/threats.  However,  the  systems  were  designed  several 
years  back,  i.e.  typical  period  of  time  from  design  to  deploy- 
ment is  between  seven  and  ten  years.  This  means  the  systems 
were  not : 

A.  Programmed  in  higher  order  language  (HOL) 

B.  Were  not  placed  under  tight  configuration  control 

C.  Were  not  subjected  to  rigorous  life  cycle  planning  as 
required  by  DOD  5000.29  (Dl) 

Even  though  these  systems  were  developed  prior  to  the 
issuance  of  5000.29  they  have  been  recently  subjected  to 
similiar  disciplines  of  management  and  control  as  required  by 
the  policy.  In  particular,  Configuration  Management  and 
certain  aspects  of  Life  Cycle  Management  have  been  implemented. 
The  major  area  of  discrepancy  is  in  the  HOL  and  at  this 
writing  it  appears  the  cost  and  time  required  to  reprogram  is 
not  feasible.  However,  attempts  are  being  made  to  program  new 
modules  with  HOL  and  incorporate  them  into  the  operational 
programs . 
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3.  SCOPE  OF  PROJECT 

The  author's  current  prime  interest  is  in  the  overall 
management  of  computer  resources  aboard  SSNs.  However,  this 
is  a broad  subject  area  and  due  to  time  constraints  of  this 
paper,  the  full  topic  is  outside  its  scope.  Therefore  this 
paper  will  be  limited  to  the  area  of  Operational  Software 
Life  Cycle  Management  for  the  Combat  Control  Systems  Aboard 


SSNs. 


GOALS  OF  REPORT 


The  two  goals  of  this  project  are  as  follows t 

A.  Review  current  DOD  and  Navy  policy  and  procedures 
for  Operational  Life  Cycle  Management  of  Computer 
Resources  and  compare  with  the  approach  being 
implemented  for  the  Combat  Control  Software  aboard 
SSNs. 

B.  Identify  improvements /changes  to  the  current  approach. 


SECTION  II 


LITERATURE  REVIEW 


1.  POD  POLICY 


The  prime  POD  Pirective  is  5000.29  (Pl)  and  the  specific 


areas  to  be  addressed  in  this  report  are  contained  within 


paragraph  V section  C and  paragraph  V section  P.  Paragraph  V 


section  C pertains  to  Configuration  Management  of  Computer 


Resources  and  the  directive  states  the  following: 


Pefense  System  Computer  resources,  including  both 
computer  hardware  and  computer  software,  will  be  specified 
and  treated  as  configuration  items . Baseline  implementa- 
tion guidance  for  this  action  is  contained  in  POP 
Instruction  5010.21. 


Paragraph  V section  P,  Computer  Resource  Life  Cycle 


Planning,  contains  the  following: 


A computer  resource  plan  will  be  developed  prior  to 
PSARC  II,  and  will  be  maintained  throughout  the  life  cycle. 
The  purpose  of  the  plan  is  to  identify  important  Pefense 
system  computer  resources  acquisition  and  life  cycle 
planning  factor  both  direct  and  indirect,  and  to  esta- 
blish specific  e^-iidelines  to  ensure  that  these  factors  are 
adequately  considered  in  the  acquisition  planning  pro- 
cess. Examples  of  factors  to  be  addressed  are  the  following, 
as  applicable: 


1 . Responsibilities  for  integration  of  computer 
resources  in  to  the  total  Pefense  system  and 
the  determination  of  overall  system  qualify. 


2.  Personnel  requirements  for  developing  and  sup- 
porting computer  resources. 


3 .  Computer  programs  required  to  support  the  develop- 
ment, acquisition,  and  maintenance  of  computer 
equipment  and  other  computer  programs. 


Provisions  for  the  transfer  of  program  manage- 
ment responsibility  after  initial  system  operating 
capability  has  been  achieved;  provisions  for 
system/equipment  turnover. 
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The  DOD  Instruction  5010.21  (D2)  as  identified  in  para- 
graph V section  C above  is  a detailed  instruction  on  Config- 
uration Management  and  has  been  implemented  in  great  detail  at 
the  DOD  component  levels.  The  detailed  component  level  will 
be  addressed  under  the  next  subsection  "Navy  Procedures".  As 
can  be  seen  from  the  previous  paragraphs  the  5000.29  (Dl) 
directive  is  not  specific  in  the  operational  life  cycle  support 
area  and  the  main  thrust  of  the  directive  is  summarized  by  the 
following  three  statements: 

1 . It  outlines  areas  for  computer  resource  manage- 
ment . 

2.  It  establishes  a Management  Steering  Committee 
for  embedded  computer  resources  at  the 
Assistant  Secretary  of  Defense  (ASD)  level. 

3.  It  places  the  development  and  implentation  of 
procedures  at  the  DOD  component  level . 


2. 


NAVY  PROCEDURES 


With  the  development  and  implementation  responsibility  for 
the  policy  stated  in  DODD  5000.29  being  placed  on  the  DOD  com- 
ponent, the  next  documentation  to  be  reviewed  is  the  Navy's. 
The  documents  that  are  related  to  this  study  reduce  down  to  a 
small  number.  The  first  document  is  in  the  configuration 
management  area  and  is  NAVMATINST  4130. lA  (D3).  Configuration 
Management  (CM)  in  this  instruction  is  broken  into  the 
following  topics  I 

- Configuration  Identification 

- Configuration  Control 

- Configuration  Accounting 

- Configuration  Audits 

In  addition  the  instruction  spells  out  the  details  for  a 

Configuration  Control  Board  (CCB)  as  well  as  details  on 

Class  I and  Class  II  Engineering  Change  Proposals  (ECPs). 

Further  guidance  has  been  issued  from  the  Chief  of  Naval 

Material  on  Configuration  Management  per  NAVMATINST  4130. 2A 

(D4).  This  instruction  sites  the  above  CM  instruction  and 

identifies  the  following  action t 

Action  - All  components  of  the  Naval  Material  Command 
responsible  for  development,  procurement,  production 
and  maintenance  of  computer  software  associated  with 
tactical  digital  systems,  or  technical  computer 
systems  shall  review  their  existing  instructions  and 
procedures  and  initiate  necessary  changes.... 

The  remaining  applicable  documents  arei 

1.  SECNAVINST  3560.1  (D5)  v^ich  establishes  the 
documentation  necessary  to  control  computer 
programs  dt  ring  their  life  cycle. 

2.  NAVMATINST  5230.5  (D6)  which  establishes  the 
Tactical  Digital  Systems  Office  in  the  Chief  of 


SECTION  III 


SSN  OPERATIONAL  SOFTWARE  SUPPORT 
1 . DOCUMENTATION 

The  SSN  operational  life  cycle  support  is  currently  being 
performed  in  accordance  with  three  basic  documents  which  were 
generated  by  the  Naval  Underwater  Systems  Center  (NUSC), 
Newport,  RI  and  approved  by  the  Naval  Sea  Systems  Command 
(NAVSEA) . 

The  first  document  is  "The  Plan  for  the  Management  of  the 
Life  Cycle  Support  Activity"  dated  15  April  1976  (Dl2).  It 
contains  detailed  information  on  the  upper  management 
structure,  from  the  Chief  of  Naval  Operations  down  to  sub- 
system agencies.  Life  Cycle  Support  Organization,  Operational/ 
Test  facilities  and  outlines  of  required  funding. 

The  second  document  is  "A  Plan  for  the  Management  of 
Software  Maintenance  Facility"  dated  23  November  1976  (Dl3). 
This  document  is  an  extension  of  the  previous  document  with 
detailed  block  diagrams  of  hardware  layout  and  facilities  and 
outlines  of  required  funding. 

The  third  document  deals  with  "Configuration  Management 
Plan  for  Life  Cycle  Support  of  SSN  Operational  Computer 
Programs",  dated  15  December  1976  (Dl4) . This  document  also 
addresses  the  mcinagement  organization,  and  addresses  the 
specific  cycles  for  review  cind  approval  of  software.  The 
main  thrust  of  the  document  is  the  configuration  management 
of  the  software.  This  has  been  patterned  after  the  procedures 
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2.  ORGANIZATION 
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Figure  1 is  a modification  to  the  Organization  Chart 
provided  in  (Dl3).  The  modification  is  made  to  focus  atten- 
tion on  the  areas  of  control  placed  on  SSN  operation  soft- 
ware. 

NAVAL  SEA  SYSTEMS  COMMAND 

The  single  point  of  contact  responsible  for  the  planning, 
programming  and  budgeting  for  the  management  of  the  operation- 
al combat  control  software  for  SSNs  is  the  Naval  Sea  Systems 
Commcind  (NAVSEA) , Code  660D.  This  assignment  was  made  via 
the  Chief  of  Naval  Material  (CNM)  (Dl5)  at  the  request  of  the 
Chief  of  Naval  Operations  (CNO)  (Dl6). 

IMPROVEMENT  CONTROL  BOARD 

The  SSN  Improvement  Control  Board  (ICB)  was  established 
by  CNO  (Dl7)  as  a means  of  reviewing  recommended  improvements 
to  operational  software,  assessing  their  cost  and  schedule 
impacts  if  implemented  and  finally  establishing  a priority  of 
those  approved.  This  board  meets  approximately  every  two  to 
three  months  and  consists  of  the  following  voting  members: 

The  Chief  of  Naval  Operations,  the  Chief  of  Naval  Material, 
the  Naval  Sea  Systems  Command,  the  Commander  Submarine  Force, 
U.S.  Atlantic  Fleet,  and  the  Commander  Submarine  Force,  U.S. 
Pacific  Fleet,  the  Chief  of  Naval  Operations  serving  as 
Chairman  of  the  Board.  In  addition  there  are  other  attendees 
such  as  the  Commander  Operational  Test  and  Evalxoation  Force, 
the  Commander,  Submarine  Development  Group,  the  Fleet  Combat 
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Direction  Systems  Support  Activity,  the  Naval  Underwater 
Systems  Center,  and  the  Naval  Ship  Engineering  Center. 


I 

I 
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Improvements  are  usually  staffed  through  the  Life  Cycle 
Support  Activity  (LCSA)  at  the  Naval  Underwater  Systems  i 

Center  prior  to  being  submitted  to  the  ICB . This  staffing  is  i 

i 

a preliminary  review  to  determine  rough  magnitudes  of  impact 
and  scope.  The  Board  reviews  the  recommended  improvements 
and  determines  if  the  improvements  should  be  approved.  If 
they  are  to  be  approved  then  the  priority  is  set  with  a 
preliminary  schedule.  The  improvements  are  then  processed 
through  the  organization  with  LCSA  tasked  to  do  the  designing, 
coding,  testing,  documenting,  and  implementing  into  the  Fleet. 
PARTICIPATING  DEVELOPER  MANAGER  (PPM) 

The  PDM  is  responsible  to  NAVSEA  for  the  design,  develop- 
ment, fabrication  and  testing  of  new  combat  control  systems, 
sub-systems  and  software  modules.  These  systems,  sub-systems 
and  software  modules  range  from  next  generation  equipment 
down  to  the  modifications  necessary  to  intergrade  new  sensor 
or  weapon  systems  into  the  combat  control  system.  The  PDM’s 
responsibility  for  a system  is  transferred  to  maintenance  ■ 

groups  after  operational  acceptance.  ■ 

' ^ 

NAVAL  SHIP  ENGINEERING  CENTER  ' 

The  SSN  Weapon  System  is  a combination  of  sensors,  dis- 
plays, weapons,  navigation,  command  eind  control  etc.  that 
utilize  the  digital  computer.  NAVSEC  has  the  responsibilities 
for  navigation,  common  program,  and  the  central  computer 
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complex  hardware. 
FLEET 


The  Fleet,  as  shown  on  the  Organization  Chart,  is  the  end 
user  of  the  system  and  thus  provides  the  prime  input  to  the 
Life  Cycle  Support  Activity  on  problem  areas  via  Problem 
Technical  Reports  (PTRs)  and  also  recommends  improvements  to 
the  ICB  for  consideration. 

LIFE  CYCLE  SUPPORT  ACTIVITY  (LCSA’) 

The  LCSA  was  established  to  correct,  update,  modify,  inte- 
grate, test  and  deliver  operational  software  to  the  Fleet. 

The  LCSA  organizational  structure  to  carry  out  these  asks  is 
depicted  in  Figure  2. 

OPERATION  BRANCH 

The  Operational  Branch  of  the  LCSA  is  a collection  of 
software  experts  who  know  the  program  down  to  the  module  level 
and  are  systems  oriented.  This  branch  is  the  focal  point  for 
operational  program  modifications,  operational  evaluation, 
software  documentation  and  is  the  corporate  configuration 
memory.  The  other  branches  will  rely  on  this  branch  for  de- 
tailed information  as  the  program  changes. 

CHANGE  CONTROL  BRANCH 

The  Change  Control  Branch  is  the  focal  point  of  Configura- 
tion Management  for  the  operational  programs  and  currently  pro- 
vides support  to  the  SSN  ICB  on  items  presented  to  the  Board. 
Within  this  Branch  there  has  been  established  an  operational 
software  program  library  which  maintains  the  master  copies 


LIFE  CYCLE  SUPPORT  ACTIVITY 
ORGANIZATION  CHART 


Figure  2 


of  all  dociimentation.  These  master  copies  represent  the  base- 
line for  each  software  configuration  item  in  the  SSN  Fleet. 

The  Configuration  item  baseline,  which  is  the  product  base- 
line, as  currently  established,  is  based  on  a Functional 
Configuration  Audit  (FCA)  and  a Phy:'ical  Configuration  Audit 
(PCA).  The  audits  are  verification  that  the  delivered  soft- 
ware meets  the  specifications  including  the  Computer  Program 
Perfomiance  Specifications  (CPPS)  {)5  »!  4 ) . Configuration 
Control  is  in  accordance  with  (D4)  and  the  Change  Control 
Board  (CCB)  which  consists  of  voting  members  from  all  branches 
of  the  LCSA . The  CCB  treats  each  proposed  change  as  an 
Engineering  Change  Proposal.  Class  I ECFs  are  submited  to 
NAVSEA  for  review  and  approval  prior  to  delivery  to  the  Fleet. 
Deliveries  to  the  Fleet,  shore  activities  and  other  users  are 
planned  to  be  accomplished  by  the  NAVSEA  Ordnance  Alteration 
(ORDALT)  procedures  (Dl8).  Details  of  the  LCSA  delivery  pack- 
age are  being  prepared.  It  is  expected  the  package  will  con- 
sist of  a complete  computer  program  on  a disk  for  each 
specific  ship,  detailed  description  of  operation  and  main- 
tenance procedures  as  well  as  any  peculiar  information  to 
that  delivery.  If  the  delivery  is  complex  then  the  LCSA 
Fleet  Liason  Branch  will  install  the  package  and  check  the 
system  out . 

Configuration  status  accounting  for  the  operational  soft- 
ware is  a large  task  since  the  Fleet  population  is  over  one 
hundred  SSNs  which  will  have  several  different  configurations. 
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The  current  approach  is  a Computerized  Information  Retrieval  v 
System  (CIRS)  under  the  Change  Control  Branch  which  tracks  | 
and  maintains  record  of  each  SSN  configuration.  The  following  1 
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types  of  information  is  maintained  in  the  CIRS  files: 


- Hardware  Master  Configuration 

- Software  Master  Configuration 

- Active/Complete  Programs  Files 

- Problem  Status  per  SSN 


FLEET  LIAISON  BRANCH 

The  Fleet  Liason  Branch  is  the  link  between  the  LCSA  and 
the  Fleet  as  well  as  other  activities  utilizing  operational 
software,  such  as  training  and  the  PDM.  In  its  liaison 
function  with  the  Fleet  this  Branch  assists  in  identifying 
problems,  reporting  problems  and  performing  other  functions 
such  as  delivering  and  checking  out  modified  software  pro- 
grams. The  baseline  information  is  under  tight  control  and 
liaison  with  the  PDM  is  maintained  in  accordance  with  (Dll). 
This  Branch  not  only  provides  information  to  the  PDM  but  also 
has  the  responsibility  to  review  new  programs  prior  to  being 
turned  over  to  the  LCSA  from  the  PDM.  This  review  is  to 
assure  that  all  applicable  documentation  is  in  accordance 
with  (D5),  to  validate  the  product  baseline  cigainst  its  doc- 
umentation and  to  recommend  to  NAVSEA  program  acceptance/re- 
jection and  deficiencies.  If  the  deficiencies  are  major  then 
NAVSEA  may  elect  to  return  the  program  to  the  PDM  for  cor- 
rection. Future  programs  under  the  PDM's  cognizance  are 
being  planned  such  that  representatives  from  the  LCSA  will 
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This  is  the  last  branch  within  the  LCSA  and  is  the  back- 


bone of  the  organization.  This  branch  designs,  obtains, 
maintains,  implements  and  operates  the  facilities  to  support 
the  full  operation  of  the  LCSA.  This  includes  complete  Combat 
Control  Systems,  Simulation/Stimulation  (SIM/STIM)  hardware 
and  software  and  all  necessary  hardware  configurations  to  re- 
flect those  in  the  Fleet . 
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SECTION  IV 


CONCLUSIONS  AND  RECOMMENDATIONS 
1.  CONCLUSIONS  AND  RECOMMENDATIONS 

In  reviewing  the  limited  policy  and  procedures  governing 
Operational  Software,  Life  Cycle  Management  (OSLCM),  it 
appears  that  the  SSN  Combat  Control  OSLCM  is  not  only  con- 
forming to  the  policy  and  procedures  but  could  be  used  as  the 
basis  for  generating  new  and  more  detailed  procedures.  There 
are  several  areas  of  concern  that  should  be  reviewed  and 
changes  considered.  These  areas  are  as  follows: 

- Utilization  of  an  outside  activity  to  provide 
Verification  and  Validation. 

- Control  of  the  product  baseline  by,  as  a minimum, 
the  Computer  Design  Specifications  vice  the 
Computer  Performance  Specifications  and  possibly 
should  be  controlled  by  the  Computer  Program 
Description  Document. 

The  Combat  Control  Systems  are  being  developed  by  the  PDM 
which  is  the  Naval  Underwater  Systems  Center,  Newport,  RI. 

The  PDM  was  established  at  the  Naval  Underwater  Systems  Center 
several  years  ago  and  given  total  systems  integration  respon- 
sibility. The  hardware  is  procured  from  several  manufactures 
and  integration,  programming  and  testing  is  performed  by  the 
PDM.  After  the  system  has  passed  operational  tests  they  are 
turned  over  to  the  Naval  Undewater  Systems  Center  LCSA  for 
operational  maintenance.  The  utilization  of  an  independent 
Verification  and  Validation  group  would  provide  the  Navy  with 
an  outside  opinion  as  to  readiness  of  a program  as  well  as  keep 
"invented  here"  attitudes  from  over  shadowing  potential  pro- 


blems . 

The  other  area  of  consideration  for  change  is  the  means 
by  which  the  baseline  is  established  and  maintained.  With  the 
baseline  identified  by  the  Computer  Performance  Specifications 
there  is  too  much  latitude  in  how  each  module  can  be  repro- 
grammed. If  the  modules  are  not  closely  controlled,  a simple 
change  could  ripple  completely  through  the  program.  This 
rippling  effect  could  create  problems  with  other  modules  in 
the  operational  programs  as  well  as  impact  integration  of 
modules,  being  developed  by  the  PDM,  into  the  operational 
programs.  Problems  due  to  the  rippling  effect  will  eventually 
translate  into  delivery  delays,  cost  increases  and  reli- 
ability. 

The  conclusions  and  recommendations  of  this  report  will 
be  provided  to  the  Naval  Sea  Systems  Command  (660D)  program 
office  for  consideration/incorporation  into  the  LCSA  manage- 


ment . 
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